One of my favorite quotes on problem solving is a paraphrase from Albert Einstein: “We cannot solve our problems with the same level of thinking that created them in the first place”. I think what Einstein is referring to here is that we need to think outside the framework of a problem to ultimately get enough perspective on it before we can get to a solution. This can mean that we need to understand not only the origin, but also the thought process that went into its creation, and that our level of thinking has to exceed the level of thinking of creation like a classic demand vs. capacity equation.
For me I interpret this as zooming out on the problem to get a better look at its behavior, and some designers may say that this is essentially out-of-the-box thinking. What I love about structural engineering, a practice governed by building codes and well-defined equations and built on principles of statics and the mechanics of materials, is that even with all of those rigid standards and equations there is still a capacity for out-of-the-box solutions. But are out-of-the box solutions as Einstein suggests the only way to solve a problem in structural engineering?
If there are out-of-the-box solutions there must surely be in-the-box solutions as well, can either be acceptable? Interestingly Paul Watzlawick, a psychologist describes just this in his work on systems thinking. In systems thinking he categorizes changes to a problem as either a First Order or Second Order change. First Order change is when a change happens within a system that is incremental, but still within the existing framework. An analogy might be your ability to turn a faucet from hot to cold, you haven’t actually changed the faucet design, the flow rate, or the physical properties of water, you are simply changing a state within that system defined by its logic. For structural engineers this might look like sizing a beam within a layout, drawing a structural detail, editing specifications, or dimensioning a drawing to get closer to a set of construction documents. Often when we hit friction, failed calculation results, and roadblocks in coordination, this is often due to us hitting into the walls of the First Order problem we are solving, and can trigger the need for a Second Order change.
For Second Order changes, the rules of the system itself are changed, which can open up a flood of new ideas and possible solutions to the problem. This might be a design feature an architect is willing to concede on, realizing that a certain structural constraint is actually a non-issue, or possibly new information from another consultant that changes the framework of the problem. As structural engineers we might try to go with a totally different structural system for a given floor level to test how well it performs. It may also be as simple as trying out a taller deck profile in a composite floor system to allow for greater unshored spans which grows beam spacing, thus reducing the number of beams required and possibly leading to increased utilization. Does Second Order problem solving essentially refer to the schematic and design development phases? I would argue that it can happen at any stage, however our willingness to introduce a Second Order change may diminish the closer we get to project deadlines.
Perhaps one of the most challenging aspects of coordination is the fact that various disciplines have their own problems to solve within a shared system. A First Order change to the system may be all that’s needed for an engineer’s scope, however a Second Order change may be needed for an architect. How do we balance this in coordination? While Second Order change may be a point of contention in some instances, I would argue that it should be embraced for the good of the client. I would argue as well that it may even make business sense to push for Second Order change and encourage volatility, especially early on in the process to help reshape a problem when needed. What are your thoughts on First Order and Second Order change?
